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Abstract 


Many protocols make use of identifiers consisting of constants and 
other well-known values. Even after a protocol has been defined and 
deployment has begun, new values may need to be assigned (e.g., fora 
new option type in DHCP, or a new encryption or authentication 
transform for IPsec). To ensure that such quantities have consistent 
values and interpretations across all implementations, their 
assignment must be administered by a central authority. For IETF 
protocols, that role is provided by the Internet Assigned Numbers 
Authority (IANA). 


In order for IANA to manage a given namespace prudently, it needs 
guidelines describing the conditions under which new values can be 
assigned or when modifications to existing values can be made. If 
IANA is expected to play a role in the management of a namespace, 
IANA must be given clear and concise instructions describing that 
role. This document discusses issues that should be considered in 
formulating a policy for assigning values to a namespace and provides 
guidelines for authors on the specific text that must be included in 
documents that place demands on IANA. 


This document obsoletes RFC 2434. 
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1. Introduction 


Many protocols make use of fields that contain constants and other 
well-known values (e.g., the Protocol field in the IP header [IP] or 
MIME media types [MIME-REG]). Even after a protocol has been defined 
and deployment has begun, new values may need to be assigned (e.g., a 
new option type in DHCP [DHCP-OPTIONS] or a new encryption or 
authentication transform for IPsec [IPSEC]). To ensure that such 
fields have consistent values and interpretations in different 
implementations, their assignment must be administered by a central 
authority. For IETF protocols, that role is provided by the Internet 
Assigned Numbers Authority (IANA) [IANA-MOU]. 


In this document, we call the set of possible values for such a field 
a "namespace"; its actual value may be a text string, a number, or 
another kind of value. The binding or association of a specific 
value with a particular purpose within a namespace is called an 
assigned number (or assigned value, or sometimes a "code point", 
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"protocol constant", or "protocol parameter"). Each assignment of a 
value in a namespace is called a registration. 


In order for IANA to manage a given namespace prudently, it needs 
guidelines describing the conditions under which new values should be 
assigned or when (and how) modifications to existing values can be 
made. This document provides guidelines to authors on what sort of 
text should be added to their documents in order to provide IANA 
clear guidelines, and it reviews issues that should be considered in 
formulating an appropriate policy for assigning numbers to name 
spaces. 


Not all namespaces require centralized administration. In some 
cases, it is possible to delegate a namespace in such a way that 
further assignments can be made independently and with no further 
(central) coordination. In the Domain Name System, for example, IANA 
only deals with assignments at the higher levels, while subdomains 
are administered by the organization to which the space has been 
delegated. As another example, Object Identifiers (OIDs) as defined 
by the ITU are also delegated [ASSIGNED]; IANA manages the subtree 
rooted at "iso.org.dod.internet" (1.3.6.1) . When a namespace is 
delegated, the scope of IANA is limited to the parts of the namespace 
where IANA has authority. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [KEYWORDS]. 
For this document, "the specification" as used by RFC 2119 refers to 
the processing of protocol documents within the IETF standards 


process. 
2. Why Management of a Namespace May Be Necessary 
One issue to consider in managing a namespace is its size. If the 
space is small and limited in size, assignments must be made 
carefully to prevent exhaustion of the space. If the space is 
essentially unlimited, on the other hand, potential exhaustion will 
probably not be a practical concern at all. Even when the space is 


essentially unlimited, however, it is usually desirable to have at 
least a minimal review prior to assignment in order to: 


- prevent the hoarding of or unnecessary wasting of values. For 
example, if the space consists of text strings, it may be 
desirable to prevent entities from obtaining large sets of 
strings that correspond to desirable names (e.g., existing 
company names). 
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- provide a sanity check that the request actually makes sense and 
is necessary. Experience has shown that some level of minimal 
review from a subject matter expert is useful to prevent 
assignments in cases where the request is malformed or not 
actually needed (i.e., an existing assignment for an essentially 
equivalent service already exists). 


A second consideration is whether it makes sense to delegate the 
namespace in some manner. This route should be pursued when 
appropriate, as it lessens the burden on IANA for dealing with 
assignments. 


A third, and perhaps most important, consideration concerns potential 
impact on the interoperability of unreviewed extensions. Proposed 
protocol extensions generally benefit from community review; indeed, 
review is often essential to avoid future interoperability problems 
[PROTOCOL-EXT]. 


When the namespace is essentially unlimited and there are no 
potential interoperability issues, assigned numbers can safely be 
given out to anyone without any subjective review. In such cases, 
IANA can make assignments directly, provided that IANA is given 
specific instructions on what types of requests it should grant, and 
what information must be provided as part of a well-formed request 
for an assigned number. 


3. Designated Experts 
3.1. The Motivation for Designated Experts 


It should be noted that IANA does not create or define assignment 
policy itself; rather, it carries out policies that have been defined 
by others and published in RFCs. IANA must be given a set of 
guidelines that allow it to make allocation decisions with minimal 
subjectivity and without requiring any technical expertise with 
respect to the protocols that make use of a registry. 


In many cases, some review of prospective allocations is appropriate, 
and the question becomes who should perform the review and what is 
the purpose of the review. One might think that an IETF working 
group (WG) familiar with the namespace at hand should be consulted. 
In practice, however, WGs eventually disband, so they cannot be 
considered a permanent evaluator. It is also possible for namespaces 
to be created through individual submission documents, for which no 
WG is ever formed. 
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One way to ensure community review of prospective assignments is to 
have the requester submit a document for publication as an RFC. Such 
an action helps ensure that the specification is publicly and 
permanently available, and it allows some review of the specification 
prior to publication and assignment of the requested code points. 
This is the preferred way of ensuring review, and is particularly 
important if any potential interoperability issues can arise. For 
example, some assignments are not just assignments, but also involve 
an element of protocol specification. A new option may define fields 
that need to be parsed and acted on, which (if specified poorly) may 
not fit cleanly with the architecture of other options or the base 
protocols on which they are built. 


In some cases, however, the burden of publishing an RFC in order to 
get an assignment is excessive. However, it is generally still 
useful (and sometimes necessary) to discuss proposed additions on a 
mailing list dedicated to the purpose (e.g., the ietf-types@iana.org 
for media types) or on a more general mailing list (e.g., that of a 
current or former IETF WG). Such a mailing list provides a way for 
new registrations to be publicly reviewed prior to getting assigned, 
or gives advice to persons wanting help in understanding what a 
proper registration should contain. 


While discussion on a mailing list can provide valuable technical 
feedback, opinions may vary and discussions may continue for some 
time without clear resolution. In addition, IANA cannot participate 
in all of these mailing lists and cannot determine if or when such 
discussions reach consensus. Therefore, IANA relies on a "designated 
expert" for advice regarding the specific question of whether an 
assignment should be made. The designated expert is an individual 
who is responsible for carrying out an appropriate evaluation and 
returning a recommendation to IANA. 


It should be noted that a key motivation for having designated 
experts is for the IETF to provide IANA with a subject matter expert 
to whom the evaluation process can be delegated. IANA forwards 
requests for an assignment to the expert for evaluation, and the 
expert (after performing the evaluation) informs IANA as to whether 
or not to make the assignment or registration. 


3.2. The Role of the Designated Expert 


The designated expert is responsible for initiating and coordinating 
the appropriate review of an assignment request. The review may be 
wide or narrow, depending on the situation and the judgment of the 
designated expert. This may involve consultation with a set of 
technology experts, discussion on a public mailing list, consultation 
with a working group (or its mailing list if the working group has 
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disbanded), etc. Ideally, the designated expert follows specific 
review criteria as documented with the protocol that creates or uses 


the namespace. (See the IANA Considerations sections of [RFC3748] 
and [RFC3575] for examples that have been done for specific 
namespaces.) 


Designated experts are expected to be able to defend their decisions 
to the IETF community, and the evaluation process is not intended to 
be secretive or bestow unquestioned power on the expert. Experts are 
expected to apply applicable documented review or vetting procedures, 
or in the absence of documented criteria, follow generally accepted 
norms, e.g., those in Section 3.3. 


Section 5.2 discusses disputes and appeals in more detail. 


Designated experts are appointed by the IESG (normally upon 
recommendation by the relevant Area Director). They are typically 
named at the time a document creating or updating a namespace is 
approved by the IESG, but as experts originally appointed may later 
become unavailable, the IESG will appoint replacements if necessary. 


For some registries, it has proven useful to have multiple designated 
experts. Sometimes those experts work together in evaluating a 
request, while in other cases additional experts serve as backups. 

In cases of disagreement among those experts, it is the 
responsibility of those experts to make a single clear recommendation 
to IANA. It is not appropriate for IANA to resolve disputes among 
experts. In extreme situations (e.g., deadlock), the IESG may need 
to step in to resolve the problem. 


In registries where a pool of experts evaluates requests, the pool 
should have a single chair responsible for defining how requests are 
to be assigned to and reviewed by experts. In some cases, the expert 
pool may consist of a primary and backups, with the backups involved 
only when the primary expert is unavailable. In other cases, IANA 
might assign requests to individual members in sequential or 
approximate random order. In the event that IANA finds itself having 
received conflicting advice from its experts, it is the 
responsibility of the pool’s chair to resolve the issue and provide 
IANA with clear instructions. 


Since the designated experts are appointed by the IESG, they may be 
removed by the IESG. 
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3.3. Designated Expert Reviews 


In the eight years since RFC 2434 was published and has been put to 
use, experience has led to the following observations: 


- A designated expert must respond in a timely fashion, normally 
within a week for simple requests to a few weeks for more 
complex ones. Unreasonable delays can cause significant 
problems for those needing assignments, such as when products 
need code points to ship. This is not to say that all reviews 
can be completed under a firm deadline, but they must be 
started, and the requester and IANA should have some 
transparency into the process if an answer cannot be given 
quickly. 


- If a designated expert does not respond to IANA’s requests 
within a reasonable period of time, either with a response or 
with a reasonable explanation for the delay (e.g., some requests 
may be particularly complex), and if this is a recurring event, 
IANA must raise the issue with the IESG. Because of the 
problems caused by delayed evaluations and assignments, the IESG 
should take appropriate actions to ensure that the expert 
understands and accepts his or her responsibilities, or appoint 
a new expert. 


-— The designated expert is not required to personally bear the 
burden of evaluating and deciding all requests, but acts as a 
shepherd for the request, enlisting the help of others as 
appropriate. In the case that a request is denied, and 
rejecting the request is likely to be controversial, the expert 
should have the support of other subject matter experts. That 
is, the expert must be able to defend a decision to the 
community as a whole. 


In the case where a designated expert is used, but there are no 
specific documented criteria for performing an evaluation, the 
presumption should be that a code point should be granted, unless 
there is a compelling reason to the contrary. Possible reasons to 
deny a request include: 


- scarcity of code points, where the finite remaining code points 
should be prudently managed, or when a request for a large 
number of code points is made, when a single code point is the 
norm. 


- documentation is not of sufficient clarity to evaluate or ensure 
interoperability. 
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- the code point is needed for a protocol extension, but the 
extension is not consistent with the documented (or generally 
understood) architecture of the base protocol being extended, 
and would be harmful to the protocol if widely deployed. It is 
not the intent that "inconsistencies" refer to minor differences 
"of a personal preference nature". Instead, they refer to 
significant differences such as inconsistencies with the 
underlying security model, implying a change to the semantics of 
an existing message type or operation, requiring unwarranted 
changes in deployed systems (compared with alternate ways of 
achieving a similar result), etc. 


- the extension would cause problems with existing deployed 
systems. 


- the extension would conflict with one under active development 
by the IETF, and having both would harm rather than foster 
interoperability. 


4. Creating a Registry 


Creating a registry involves describing the namespaces to be created, 
an initial set of assignments (if appropriate), and guidelines on how 
future assignments are to be made. 


Once a registry has been created, IANA records assignments that have 
been made. The following labels describe the status of an individual 
(or range) of assignments: 


Private Use: Private use only (not assigned), as described in 
Section 4.1. 


Experimental: Available for experimental use as described in 
[EXPERIMENTATION]. IANA does not record specific 
assignments for any particular use. 


Unassigned: Unused and available for assignment via documented 
procedures. 


Reserved: Not to be assigned. Reserved values are held for 
special uses, such as to extend the namespace when it become 
exhausted. Reserved values are not available for general 
assignment. 
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4.1. Well-Known IANA Policy Definitions 


The following are some defined policies, some of which are in use 
today. These cover a range of typical policies that have been used 
to date to describe the procedure for assigning new values in a 


namespace. It is not required that documents use these terms; the 
actual requirement is that the instructions to IANA are clear and 
unambiguous. However, use of these terms is RECOMMENDED where 


possible, since their meaning is widely understood. 


Private Use - For private or local use only, with the type and 
purpose defined by the local site. No attempt is made to 
prevent multiple sites from using the same value in 
different (and incompatible) ways. There is no need for 
IANA to review such assignments (since IANA does not record 
them) and assignments are not generally useful for broad 
interoperability. It is the responsibility of the sites 
making use of the Private Use range to ensure that no 
conflicts occur (within the intended scope of use). 


Examples: Site-specific options in DHCP [DHCP-IANA], Fibre 
Channel Port Type Registry [RFC4044], Exchange Types in the 
IKEv2 header [RFC4306]. 


Experimental Use - Similar to private or local use only, with the 
purpose being to facilitate experimentation. See 
[EXPERIMENTATION] for details. 


Example: Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, 
UDP, and TCP Headers [RFC4727]. 


Hierarchical Allocation - Delegated managers can assign values 
provided they have been given control over that part of the 
namespace. IANA controls the higher levels of the namespace 
according to one of the other policies. 


Examples: DNS names, Object Identifiers, IP addresses. 


First Come First Served - Assignments are made to anyone ona 
first come, first served basis. There is no substantive 
review of the request, other than to ensure that it is 
well-formed and doesn’t duplicate an existing assignment. 
However, requests must include a minimal amount of clerical 
information, such as a point of contact (including an email 
address) and a brief description of how the value will be 
used. Additional information specific to the type of value 
requested may also need to be provided, as defined by the 
namespace. For numbers, the exact value is generally 
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assigned by IANA; with names, specific text strings can 
usually be requested. 

Examples: SASL mechanism names [RFC4422], LDAP Protocol 
Mechanisms, and LDAP Syntax [RFC4520]. 
Expert Review (or Designated Expert) - approval by a Designated 


Expert is required. The required documentation and review 
criteria for use by the Designated Expert should be provided 
when defining the registry. For example, see Sections 6 and 
7.2 in [RFC3748]. 


Examples: EAP Method Types [RFC3748], HTTP Digest AKA 
algorithm versions [RFC4169], URI schemes [RFC4395], GEOPRIV 
Location Types [RFC4589]. 


Specification Required - Values and their meanings must be 


documented in a permanent and readily available public 
specification, in sufficient detail so that interoperability 
between independent implementations is possible. When used, 
Specification Required also implies use of a Designated 
Expert, who will review the public specification and 
evaluate whether it is sufficiently clear to allow 
interoperable implementations. The intention behind 
"permanent and readily available" is that a document can 
reasonably be expected to be findable and retrievable long 
after IANA assignment of the requested value. Publication 
of an RFC is an ideal means of achieving this requirement, 
but Specification Required is intended to also cover the 
case of a document published outside of the RFC path. For 
RFC publication, the normal RFC review process is expected 
to provide the necessary review for interoperability, though 
the Designated Expert may be a particularly well-qualified 
person to perform such a review. 


Examples: Diffserv-aware TE Bandwidth Constraints Model 
Identifiers [RFC4124], TLS ClientCertificateType Identifiers 
[RFC4346], ROHC Profile Identifiers [RFC4995]. 


RFC Required - RFC publication (either as an IETF submission or as 


an RFC Editor Independent submission [RFC3932]) suffices. 
Unless otherwise specified, any type of RFC is sufficient 
(e.g., Informational, Experimental, Standards Track, etc.). 


Narten & Alvestrand Best Current Practice [Page 10] 


RFC 5226 IANA Considerations Section in RFCs May 2008 


IETF Review - (Formerly called "IETF Consensus" in 
[IANA-CONSIDERATIONS]) New values are assigned only through 
RFCs that have been shepherded through the IESG as AD- 
Sponsored or IETF WG Documents [RFC3932] [RFC3978]. The 
intention is that the document and proposed assignment will 
be reviewed by the IESG and appropriate IETF WGs (or 
experts, if suitable working groups no longer exist) to 
ensure that the proposed assignment will not negatively 
impact interoperability or otherwise extend IETF protocols 
in an inappropriate or damaging manner. 


To ensure adequate community review, such documents are 
shepherded through the IESG as AD-sponsored (or WG) 
documents with an IETF Last Call. 


Examples: IPSECKEY Algorithm Types [RFC4025], 
Accounting-Auth-Method AVP values in DIAMETER [RFC4005], TLS 
Handshake Hello Extensions [RFC4366]. 


Standards Action - Values are assigned only for Standards Track 
RFCs approved by the IESG. 


Examples: BGP message types [RFC4271], Mobile Node 
Identifier option types [RFC4283], DCCP Packet Types 
[RFC4340]. 


IESG Approval - New assignments may be approved by the IESG. 
Although there is no requirement that the request be 
documented in an RFC, the IESG has discretion to request 
documents or other supporting materials on a case-by-case 
basis. 


IESG Approval is not intended to be used often or as a 
"common case"; indeed, it has seldom been used in practice 
during the period RFC 2434 was in effect. Rather, it is 
intended to be available in conjunction with other policies 
as a fall-back mechanism in the case where one of the other 
allowable approval mechanisms cannot be employed in a timely 
fashion or for some other compelling reason. IESG Approval 
is not intended to circumvent the public review processes 
implied by other policies that could have been employed for 
a particular assignment. IESG Approval would be 
appropriate, however, in cases where expediency is desired 
and there is strong consensus for making the assignment 
(e.g., WG consensus). 
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The following guidelines are suggested for any evaluation 
under IESG Approval: 


-— The IESG can (and should) reject a request if another path 
for registration is available that is more appropriate and 
there is no compelling reason to use that path. 


- Before approving a request, the community should be 
consulted, via a "call for comments" that provides as much 
information as is reasonably possible about the request. 


Examples: IPv4 Multicast address assignments [RFC3171], IPv4 
IGMP Type and Code values [RFC3228], Mobile IPv6 Mobility 
Header Type and Option values [RFC3775]. 


It should be noted that it often makes sense to partition a namespace 
into multiple categories, with assignments within each category 
handled differently. For example, many protocols now partition 
namespaces into two (or even more) parts, where one range is reserved 
for Private or Experimental Use, while other ranges are reserved for 
globally unique assignments assigned following some review process. 
Dividing a namespace into ranges makes it possible to have different 
policies in place for different ranges. 


Examples: LDAP [RFC4520], Pseudowire Edge to Edge Emulation (PWE3) 
[RFC4446]. 


4.2. What to Put in Documents That Create a Registry 


The previous sections presented some issues that should be considered 
in formulating a policy for assigning values in namespaces. It is 
the working group and/or document author’s job to formulate an 
appropriate policy and specify it in the appropriate document. In 
almost all cases, having an explicit "IANA Considerations" section is 
appropriate. The following and later sections define what is needed 
for the different types of IANA actions. 


Documents that create a new namespace (or modify the definition of an 
existing space) and that expect IANA to play a role in maintaining 
that space (e.g., serving as a repository for registered values) MUST 
provide clear instructions on details of the namespace. In 
particular, instructions MUST include: 


1) The name of the registry (or sub-registry) being created and/or 
maintained. The name will appear on the IANA web page and will 
be referred to in future documents that need to allocate a 
value from the new space. The full name (and abbreviation, if 
appropriate) should be provided. It is highly desirable that 
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the chosen name not be easily confusable with the name of 
another registry. When creating a sub-registry, the registry 
that it is a part of should be clearly identified. When 
referring to an already existing registry, providing a URL to 
precisely identify the registry is helpful. All such URLs, 
however, will be removed from the RFC prior to final 
publication. For example, documents could contain: [TO BE 
REMOVED: This registration should take place at the following 
location: http://www.iana.org/assignments/foobar-registry] 


2) What information must be provided as part of a request in order 
to assign a new value. This information may include the need 
to document relevant security considerations, if any. 


3) The review process that will apply to all future requests fora 
value from the namespace. 


Note: When a Designated Expert is used, documents MUST NOT name 
the Designated Expert in the document itself; instead, the name 
should be relayed to the appropriate Area Director at the time 
the document is sent to the IESG for approval. 


If the request should also be reviewed on a specific public 
mailing list (such as the ietf-types@iana.org for media types), 
that mailing address should be specified. Note, however, that 
when mailing lists are specified, the requirement for a 
Designated Expert MUST also be specified (see Section 3). 


If IANA is expected to make assignments without requiring an 
outside review, sufficient guidance MUST be provided so that 
the requests can be evaluated with minimal subjectivity. 


4) The size, format, and syntax of registry entries. When 
creating a new name/number space, authors must describe any 
technical requirements on registry (and sub-registry) values 
(e.g., valid ranges for integers, length limitations on 
strings, etc.) as well as the exact format in which registry 
values should be displayed. For number assignments, one should 
specify whether values are to be recorded in decimal, 
hexadecimal, or some other format. For strings, the encoding 
format should be specified (e.g., ASCII, UTF8, etc.). Authors 
should also clearly specify what fields to record in the 
registry. 


5) Initial assignments and reservations. Clear instructions 


should be provided to identify any initial assignments or 
registrations. In addition, any ranges that are to be reserved 
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for "Private Use", "Reserved", "Unassigned", etc. should be 
clearly indicated. 


When specifying the process for making future assignments, it is 
quite acceptable to pick one (or more) of the example policies listed 


in Section 4.1 and refer to it by name. Indeed, this is the 
preferred mechanism in those cases where the sample policies provide 
the desired level of review. It is also acceptable to cite one of 


the above policies and include additional guidelines for what kind of 
considerations should be taken into account by the review process. 
For example, RADIUS [RFC3575] specifies the use of a Designated 
Expert, but includes specific additional criteria the Designated 
Expert should follow. 


For example, a document could say something like: 


This document defines a new DHCP option, entitled "FooBar" (see 
Section y), assigned a value of TBD1 from the DHCP Option space 
[to be removed upon publication: 
http://www.iana.org/assignments/bootp-dhcp-parameters] 
[DHCP-OPTIONS] [DHCP-IANA]: 


Tag Name Length Meaning 


TBD1 FooBar N FooBar server 


The FooBar option also defines an 8-bit FooType field, for which 
IANA is to create and maintain a new sub-registry entitled 
"FooType values" under the FooBar option. Initial values for the 
DHCP FooBar FooType registry are given below; future assignments 
are to be made through Expert Review [IANA-CONSIDERATIONS]. 
Assignments consist of a DHCP FooBar FooType name and its 
associated value. 


Value DHCP FooBar FooType Name Definition 

0 Reserved 

1 Frobnitz See Section y.1 
2 NitzFrob See Section y.2 
3-254 Unassigned 

255 Reserved 


For examples of documents that provide detailed guidance to IANA 
on the issue of assigning numbers, consult [RFC2929], [RFC3575], 
[RFC3968], and [RFC4520]. 
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3. Updating IANA Guidelines for Existing Registries 


Updating the registration process for an already existing (i.e., 
previously created) namespace (whether created explicitly or 
implicitly) follows a process similar to that used when creating a 
new namespace. That is, a document is produced that makes reference 
to the existing namespace and then provides detailed guidelines for 
handling assignments in each individual namespace. Such documents 
are normally processed as Best Current Practices (BCPs) 
[IETF-PROCESS]. 


Example documents that updated the guidelines for managing (then) 
pre-existing registries include: [RFC2929], [RFC3228], and [RFC3575]. 


Registering New Values in an Existing Registry 
1. What to Put in Documents When Registering Values 


Often, documents request an assignment from an already existing 
namespace (i.e., one created by a previously published RFC). In such 
cases: 


- Documents should clearly identify the namespace in which each 
value is to be registered. If the registration goes into a 
sub-registry, the author should clearly describe where the 
assignment or registration should go. It is helpful to use the 
exact namespace name as listed on the IANA web page (and 
defining RFC), and cite the RFC where the namespace is defined. 


Note 1: There is no need to mention what the assignment policy 
for new assignments is, as that should be clear from the 
references. 


Note 2: When referring to an existing registry, providing a URL 
to precisely identify the registry is helpful. Such URLs, 
however, should usually be removed from the RFC prior to final 
publication, since IANA URLS are not guaranteed to be stable in 
the future. In cases where it is important to include a URL in 
the document, IANA should concur on its inclusion. 


As an example, documents could contain: [TO BE REMOVED: This 
registration should take place at the following location: 
http://www.iana.org/assignments/foobar-registry] 


- Each value requested should be given a unique reference. When 
the value is numeric, use the notation: TBD1, TBD2, etc. 
Throughout the document where an actual IANA-assigned value 
should be filled in, use the "TBDx" notation. This helps ensure 
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that the final RFC has the correct assigned values inserted in 
all of the relevant places where the value is expected to appear 
in the final document. For values that are text strings, a 
specific name can be suggested. IANA will normally assign the 
name, unless it conflicts with a name already in use. 


- Normally, the values to be used are chosen by IANA and documents 
should specify values of "TBD". However, in some cases, a value 
may have been used for testing or in early implementations. In 
such cases, it is acceptable to include text suggesting what 
specific value should be used (together with the reason for the 
choice). For example, one might include the text "the value XXX 
is suggested as it is used in implementations". However, it 
should be noted that suggested values are just that; IANA will 
attempt to assign them, but may find that impossible, if the 
proposed number has already been assigned for some other use. 


For some registries, IANA has a long-standing policy prohibiting 
assignment of names or codes on a vanity or organization name 
basis, e.g., codes are always assigned sequentially unless there 
is a strong reason for making an exception. Nothing in this 
document is intended to change those policies or prevent their 
future application. 


-— The IANA Considerations section should summarize all of the IANA 
actions, with pointers to the relevant sections elsewhere in the 
document as appropriate. When multiple values are requested, it 
is generally helpful to include a summary table. It is also 
helpful for this table to be in the same format as it should 
appear on the IANA web site. For example: 


Value Description Reference 


TBD1 Foobar [RFCXXXX ] 


Note: In cases where authors feel that including the full table is 
too verbose or repetitive, authors should still include the table, 
but may include a note asking that the table be removed prior to 
publication of the final RFC. 


As an example, the following text could be used to request assignment 
of a DHCPv6 option number: 


IANA has assigned an option code value of TBD1 to the DNS 
Recursive Name Server option and an option code value of TBD2 to 
the Domain Search List option from the DHCP option code space 
defined in Section 24.3 of RFC 3315. 
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5.2. Updating Registrations 


Registrations are a request to assign a new value, including the 
related information needed to evaluate and document the request. 
Even after a number has been assigned, some types of registrations 
contain additional information that may need to be updated over time. 
For example, MIME media types, character sets, and language tags, 
etc. typically include more information than just the registered 
value itself. Example information can include point-of-contact 
information, security issues, pointers to updates, literature 
references, etc. In such cases, the document defining the namespace 
must clearly state who is responsible for maintaining and updating a 
registration. In different cases, it may be appropriate to specify 
one or more of the following: 


- Let the author update the registration, subject to the same 
constraints and review as with new registrations. 


—- Allow some mechanism to attach comments to the registration, for 
cases where others have significant objections to claims ina 
registration, but the author does not agree to change the 
registration. 


- Designate the IESG, a Designated Expert, or another entity as 
having the right to change the registrant associated with a 
registration and any requirements or conditions on doing so. 
This is mainly to get around the problem when a registrant 
cannot be reached in order to make necessary updates. 


5.3. Overriding Registration Procedures 


Since RFC 2434 was published, experience has shown that the 
documented IANA considerations for individual protocols do not always 
adequately cover the reality after the protocol is deployed. For 
example, many older routing protocols do not have documented, 
detailed IANA considerations. In addition, documented IANA 
considerations are sometimes found to be too stringent to allow even 
working group documents (for which there is strong consensus) to 
obtain code points from IANA in advance of actual RFC publication. 

In other cases, the documented procedures are unclear or neglected to 
cover all the cases. In order to allow assignments in individual 
cases where there is strong IETF consensus that an allocation should 
go forward, but the documented procedures do not support such an 
assignment, the IESG is granted authority to approve assignments in 


such cases. The intention is not to overrule properly documented 
procedures, or to obviate the need for protocols to properly document 
their IANA considerations. Instead, the intention is to permit 


assignments in individual cases where it is obvious that the 
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6. 


6. 


assignment should just be made, but updating the IANA process just to 
assign a particular code point is viewed as too heavy a burden. 


In general, the IETF would like to see deficient IANA registration 
procedures for a namespace revised through the IETF standards 
process, but not at the cost of unreasonable delay for needed 
assignments. If the IESG has had to take the action in this section, 
it is a strong indicator that the IANA registration procedures should 
be updated, possibly in parallel with ongoing protocol work. 


Miscellaneous Issues 
1. When There Are No IANA Actions 


Before an Internet-Draft can be published as an RFC, IANA needs to 
know what actions (if any) it needs to perform. Experience has shown 
that it is not always immediately obvious whether a document has no 
IANA actions, without reviewing the document in some detail. In 
order to make it clear to IANA that it has no actions to perform (and 
that the author has consciously made such a determination), such 
documents should include an IANA Considerations section that states: 


This document has no IANA actions. 


This statement, or an equivalent, must only be inserted after the WG 
or individual submitter has carefully verified it to be true. Using 
such wording as a matter of "boilerplate" or without careful 
consideration can lead to incomplete or incorrect IANA actions being 
performed. 


If a specification makes use of values from a namespace that is not 
managed by IANA, it may be useful to note this fact, e.g., with 
wording such as: 


The values of the Foobar parameter are assigned by the Barfoo 
registry on behalf of the Rabfoo Forum. Therefore, this document 
has no IANA actions. 


In some cases, the absence of IANA-assigned values may be considered 
valuable information for future readers; in other cases, it may be 
considered of no value once the document has been approved, and may 
be removed before archival publication. This choice should be made 
clear in the draft, for example, by including a sentence such as 


[RFC Editor: please remove this section prior to publication. ] 


or 
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[RFC Editor: please do not remove this section. ] 
6.2. Namespaces Lacking Documented Guidance 


For all existing RFCs that either explicitly or implicitly rely on 
TANA to evaluate assignments without specifying a precise evaluation 
policy, IANA (in consultation with the IESG) will continue to decide 
what policy is appropriate. Changes to existing policies can always 
be initiated through the normal IETF consensus process. 


All future RFCs that either explicitly or implicitly rely on IANA to 
register or otherwise manage namespace assignments MUST provide 
guidelines for managing the namespace. 


6.3. After-the-Fact Registrations 


Occasionally, IANA becomes aware that an unassigned value from a 
managed namespace is in use on the Internet or that an assigned value 
is being used for a different purpose than originally registered. 
IANA will not condone such misuse; i.e., procedures of the type 
described in this document MUST be applied to such cases. In the 
absence of specifications to the contrary, values may only be 
reassigned for a different purpose with the consent of the original 
assignee (when possible) and with due consideration of the impact of 
such a reassignment. In cases of likely controversy, consultation 
with the IESG is advised. 


6.4. Reclaiming Assigned Values 


Reclaiming previously assigned values for reuse is tricky, because 
doing so can lead to interoperability problems with deployed systems 
still using the assigned values. Moreover, it can be extremely 
difficult to determine the extent of deployment of systems making use 
of a particular value. However, in cases where the namespace is 
running out of unassigned values and additional ones are needed, it 
may be desirable to attempt to reclaim unused values. When 
reclaiming unused values, the following (at a minimum) should be 
considered: 


- Attempts should be made to contact the original party to which a 
value is assigned, to determine if the value was ever used, and 
if so, the extent of deployment. (In some cases, products were 
never shipped or have long ceased being used. In other cases, 
it may be known that a value was never actually used at all.) 
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- Reassignments should not normally be made without the 
concurrence of the original requester. Reclamation under such 
conditions should only take place where there is strong evidence 
that a value is not widely used, and the need to reclaim the 
value outweighs the cost of a hostile reclamation. In any case, 
IESG Approval is needed in this case. 


- It may be appropriate to write up the proposed action and 
solicit comments from relevant user communities. In some cases, 
it may be appropriate to write an RFC that goes through a formal 
IETF process (including IETF Last Call) as was done when DHCP 
reclaimed some of its "Private Use" options [RFC3942]. 


7. Appeals 


Appeals of registration decisions made by IANA can be made using the 
normal IETF appeals process as described in Section 6.5 of 
[IETF-PROCESS]. Specifically, appeals should be directed to the 
IESG, followed (if necessary) by an appeal to the IAB, etc. 


8. Mailing Lists 


All IETF mailing lists associated with evaluating or discussing 
assignment requests as described in this document are subject to 
whatever rules of conduct and methods of list management are 

currently defined by Best Current Practices or by IESG decision. 


9. Security Considerations 


Information that creates or updates a registration needs to be 
authenticated and authorized. IANA updates registries according to 
instructions in published RFCs and from the IESG. It also may accept 
clarifications from document authors, relevant WG chairs, Designated 
Experts, and mail list participants, too. 


Information concerning possible security vulnerabilities of a 
protocol may change over time. Likewise, security vulnerabilities 
related to how an assigned number is used (e.g., if it identifies a 
protocol) may change as well. As new vulnerabilities are discovered, 
information about such vulnerabilities may need to be attached to 
existing registrations, so that users are not misled as to the true 
security issues surrounding the use of a registered number. 


An analysis of security issues is generally required for all 
protocols that make use of parameters (data types, operation codes, 
keywords, etc.) used in IETF protocols or registered by IANA. Such 
security considerations are usually included in the protocol document 
[RFC3552]. It is the responsibility of the IANA considerations 
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iated with a particular registry to specify what (if any) 
ity considerations must be provided when assigning new values, 
he process for reviewing such claims. 


nges Relative to RFC 2434 


Changes include: 


Narten & 


Major reordering of text to expand descriptions and to better 
group topics such as "updating registries" vs. "creating new 
registries", in order to make it easier for authors to find the 
text most applicable to their needs. 


Numerous editorial changes to improve readability. 


Changed the term "IETF Consensus" to "IETF Review" and added 
more clarifications. History has shown that people see the 
words "IETF Consensus" (without consulting the actual 
definition) and are quick to make incorrect assumptions about 
what the term means in the context of IANA Considerations. 


Added "RFC Required" to list of defined policies. 


Much more explicit directions and examples of "what to put in 
RFCs". 


"Specification Required" now implies use of a Designated Expert 
to evaluate specs for sufficient clarity. 


Significantly changed the wording in Section 3. Main purpose is 
to make clear that Expert Reviewers are accountable to the 
community, and to provide some guidance for review criteria in 


the default case. 


Changed wording to remove any special appeals path. The normal 
RFC 2026 appeals path is used. 


Added a section about reclaiming unused value. 
Added a section on after-the-fact registrations. 
Added a section indicating that mailing lists used to evaluate 


possible assignments (e.g., by a Designated Expert) are subject 
to normal IETF rules. 
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